Vehicle Routing Example: Upgrade to 0.5.1 and fix JS issues#2
Merged
blackopsrepl merged 116 commits intoSolverForge:fix/vehicle-routing/prathje-js-fixfrom Feb 1, 2026
Conversation
Create FUNDING.yml
…verForge branding - Add score analysis API endpoint and modal UI - Add room stability constraint with comprehensive tests - Add SolverForge branding to header/footer - Update frontend to handle both string ID and object references - Add README.md with setup instructions - Improve test coverage for all constraint types
…verForge branding - Add score analysis API endpoint and modal UI - Add room stability constraint with comprehensive tests - Add SolverForge branding to header/footer - Update frontend to handle both string ID and object references - Add README.md with setup instructions - Improve test coverage for all constraint types
…per-meeting violation display Replace broken frontend conflict detection with solver's constraint analysis API. - Add analyzeCache to store per-meeting violations from /schedules/analyze - Fetch constraint analysis when score is available - Parse justification.facts to extract assignment IDs - Fix getConstraintType() to correctly identify constraint severity (hard/medium/soft) - Hide soft violations in timeline (optimization trade-offs, not errors) - Show only hard/medium violations with red/yellow colors - Update workload badges to use neutral colors (blue/gray instead of red) - Green meetings indicate feasible solution (0 hard/medium violations)
…per-meeting violation display Replace broken frontend conflict detection with solver's constraint analysis API. - Add analyzeCache to store per-meeting violations from /schedules/analyze - Fetch constraint analysis when score is available - Parse justification.facts to extract assignment IDs - Fix getConstraintType() to correctly identify constraint severity (hard/medium/soft) - Hide soft violations in timeline (optimization trade-offs, not errors) - Show only hard/medium violations with red/yellow colors - Update workload badges to use neutral colors (blue/gray instead of red) - Green meetings indicate feasible solution (0 hard/medium violations)
…onstraints The required_and_preferred_attendance_conflict and preferred_attendance_conflict constraints were missing filters for assigned meetings (starting_time_grain != None). This caused the constraints to fail when joining with unassigned meetings, preventing proper detection of attendance conflicts. Without these filters, people could be scheduled for overlapping meetings without triggering medium-severity violations, allowing situations like: - Person required at Meeting A (10:30-13:30) - Same person preferred at Meeting B (11:15-14:15, overlaps 11:15-13:30) - No medium violation detected (should penalize by 9 time grains) This matches the Java implementation which uses: .forEachIncludingUnassigned(MeetingAssignment.class) .filter(assignment -> assignment.getStartingTimeGrain() != null) Also adds comprehensive test coverage for both constraints.
…onstraints The required_and_preferred_attendance_conflict and preferred_attendance_conflict constraints were missing filters for assigned meetings (starting_time_grain != None). This caused the constraints to fail when joining with unassigned meetings, preventing proper detection of attendance conflicts. Without these filters, people could be scheduled for overlapping meetings without triggering medium-severity violations, allowing situations like: - Person required at Meeting A (10:30-13:30) - Same person preferred at Meeting B (11:15-14:15, overlaps 11:15-13:30) - No medium violation detected (should penalize by 9 time grains) This matches the Java implementation which uses: .forEachIncludingUnassigned(MeetingAssignment.class) .filter(assignment -> assignment.getStartingTimeGrain() != null) Also adds comprehensive test coverage for both constraints.
Remove 147-line dead code function that was never called. Constraint violation detection now uses solver's analysis API.
Remove 147-line dead code function that was never called. Constraint violation detection now uses solver's analysis API.
The extractAssignmentIds() function now handles attendance facts (RequiredAttendance, PreferredAttendance) by looking up the corresponding MeetingAssignment via meetingId. Previously, only facts with a 'meeting' property were captured, causing attendance conflicts to show green instead of red.
The extractAssignmentIds() function now handles attendance facts (RequiredAttendance, PreferredAttendance) by looking up the corresponding MeetingAssignment via meetingId. Previously, only facts with a 'meeting' property were captured, causing attendance conflicts to show green instead of red.
… extractAssignmentIds
… extractAssignmentIds
…ed UI - Rewrite logisim-view.js with isometric 3D rendering and aisle routing - Add balance_trolley_workload constraint for better distribution - Fix SSE real-time updates with proper solver state tracking - Increase default orders to 40, trolleys to 8 for realistic workload - Update sliders: orders 10-100, trolleys 3-15, buckets 2-10 - Add better error handling for generate endpoint
Update test_empty_schedule_has_score to properly use the channel-based solve() method which requires terminate flag and sender arguments.
…ging - Bump version to 0.5.0 - Add verbose-logging feature to solverforge dependency - Track solver status (SOLVING/NOT_SOLVING) in SolveJob - Expose solver_status in ScheduleDto API response - Update status to NOT_SOLVING when channel closes - Add Dockerfile and README for deployment
- Add missing quickstarts to overview table: Hello World, Portfolio Optimization, VM Placement - Reorganize table to show Rust and Python (Legacy) columns - Add detailed sections for all 8 quickstarts - Update solverforge dependency to version 0.5.0 - Add server startup message showing URL and port
…g quickstarts - meeting-scheduling: fix test_feasible.py to use /demo-data/SMALL endpoint instead of /demo-data - The /demo-data endpoint returns a list of dataset names, not actual data - Fixed test_feasible, test_analyze, and test_analyze_constraint_scores - order-picking: update test_constraints.py to use minimize_total_distance - Removed imports for minimize_distance_from_previous_step and minimize_distance_from_last_step_to_origin - These were refactored into minimize_total_distance which aggregates at trolley level - Updated test to verify total round-trip distance (to step + back to origin)
- Add Helm chart for Kubernetes deployment - Chart.yaml with version 0.5.0 - values.yaml with sensible defaults (2Gi limit, 256Mi request) - Deployment, Service, Ingress templates - Health probes using /demo-data endpoint - Update CI/CD pipeline - Add test-rust job with cargo test and build - Add employee-scheduling to build-and-push matrix - Split tests into test-rust and test-python jobs - Add rust/employee-scheduling to trigger paths
meeting-scheduling: - Update create_required_attendance and create_preferred_attendance helpers to return tuples containing both the typed attendance object and a generic Attendance object - room_stability constraint tests now use the Attendance objects (second tuple element) - Other constraint tests use the typed attendance objects (first tuple element) - This allows room_stability constraint to work with the generic Attendance class while other constraints work with typed RequiredAttendance/PreferredAttendance order-picking: - Update minimize_total_distance test to expect correct penalty - Shadow variable distance_from_previous is not triggered in constraint verification tests - Test now correctly expects only the return distance (3m) instead of round-trip (6m)
Add release/** to the CI trigger branches so that tests run on release branches in addition to main and dev branches.
When solving a schedule with 0 entities, the solver may optimize by closing the channel without sending any solutions. Update the test to handle this case gracefully instead of panicking with 'should receive solution'.
- Use Alpine Linux instead of Debian for smaller image size - Build as standalone using published solverforge crate from crates.io - Remove dependency on local solverforge-rs workspace - Build with musl target for static linking - Build context is now just rust/employee-scheduling/ (works with CI)
a0ce88d to
248da5c
Compare
Collaborator
|
Hello @prathje, thank you for trying SolverForge! The version being locked to 0.4.x is intentional until I solve shadow variable ergonomics - you'll notice that the quickstart still uses some local helpers in VRP. I'm currently reorganizing the repos and SolverForge in general to make clear:
I'll look into the JavaScript! |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Hello there!
I was just playing around with SolverForge and wanted to check out the vehicle routing example.
I stumbled upon a few small JS issues that I could fix.
Feel free to incorporate them if you want.
Cheers!
Patrick